System and Method for Authorized Digital Content Distribution

ABSTRACT

A digital content distribution system uses a Digital Rights Management Controller that performs a set of arbitrary tests against the transfer request from one user to another such as user A to user B. Assuming these tests are successful, the DRM sends an encryption key to transferring user A. This encryption key E is taken from a table of encryption key/hash pairs which have been provided to the DRM Controller by an external authority such as the content rights holder. User A encrypts the content using they key provided by the DRM controller and then optionally calculates a hash over the encrypted form of the content E(X) and returns this value to the DRM Controller. On checking the returned hash against the hash from the table the DRM controller knows that user A does indeed have the digital content X in good condition. The DRM Controller then instructs both users A and B that the transfer may proceed. The encrypted form of the content E(X) is transferred from A to B. Once the content transfer has completed B ensures that the received content has been physically written to non-volatile storage (to account for crashes etc. during the next step). B then calculates a hash over the received content and returns this value to the DRM Controller. If this value matches the value previously given then the transfer has been successful and the DRM Controller updates whatever central records are appropriate, while also returning a decrypt key to B to allow it to decrypt the content.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/737,679, filed Jan. 8, 2020, which is a divisional of U.S.application Ser. No. 14/753,385, filed Jun. 29, 2015, now issued as U.S.Pat. No. 10,536,435 which is a continuation of U.S. application Ser. No.11/341,172, filed Jan. 26, 2006, now issued as U.S. Pat. No. 9,077,691,which claims the benefit of Prov. Appl. No. 60/647,044, filed Jan. 26,2005, now expired, which are incorporated by reference herein in theirentirety.

FIELD OF THE INVENTION

The present invention relates generally to the field of digital contentdistribution in a telecommunications network and, more specifically, topayment mechanisms for the authorized legal distribution of digitalcontent within a peer-to-peer (P2P) environment.

BACKGROUND

Peer-to-peer P2P networks are networks that enable a computer user inpossession of digital content to share the digital content with otherusers without having to transfer to or download the content from acentral server. P2P networks have generally been very successful buthave existed outside of most legal frameworks. This has led toconsiderable controversy including the shutdown of many peer-to-peernetworks due to court injunctions and other legal problems. This problemappears to have been solved in conjunction with the Digital RightsManagement (DRM) issue but separating DRM and Digital ContentDistribution (DCD) has led to innovative differentiation. Even then thishas not really been solved in a generic P2P infrastructure, but hasresulted in much more centralized environments.

Current P2P solutions have been created outside of a legal framework andare subject to repeated attack from copyright holders. Their growth islimited by ongoing legality concerns in the minds of potential userswhich are fostered by the RIAA and like organizations.

Current DRM solutions tend to have originated with rights holders andthus tend to enforce additional restrictions on the use of purchasedmaterials above and beyond those which consumers have come to expectwith videocassette recorders (VCRs) and the Compact Cassette. This haslead to consumer resentment. DRM solutions also tend to be somewhatcentralized in nature leading to limited, or very expensive systems.

P2P operators have not, historically, been too concerned with contenttracking and tracability, nor with the implementation of a legal overlayon a P2P infrastructure. Traditional DRM providers view their value asbeing in the DRM solution, not in the content distribution component,for which they would typically expect to use commercially availablesolutions.

Thus, there is a need for a peer-to-peer (P2P) distribution scheme thatcan incorporate the concepts from digital rights management therebyenabling the distribution of digital content such as music, movies andbooks while providing just compensation to the owners of suchcopyrighted works.

It would be desirable to have a P2P digital content distribution systemand method that enable charging back to a prepaid account such as aprepaid mobile phone account.

Additionally, it would be desirable to have a P2P digital contentdistribution system that provides for certification of quality ofcontent thereby ensuring that the downloaded digital files are notcorrupted or contain viruses or other problems that would prohibit theirlegitimate use.

Furthermore, it would be desirable to have a P2P digital contentdistribution system that provides credits to a customer for the onwarddistribution of digital content to additional users/customers.

SUMMARY

The present invention enables the legitimate P2P distribution of digitalcontent within a legal framework in which operators do not need to havefirst hand knowledge or possession of the content thereby enablingoperators to claim the equivalent of ‘common carrier’ status in acontent environment. Two sharing users, A and B, previously registeredwith a DRM controller, find by some arbitrary method that they wish toexchange a piece of digital content, X. B requests a copy of digitalcontent X from A, which A is willing to provide and so A sends anacknowledgement back to B. Both A and B register their interest in thecontent element X with the DRM Controller. Note that in the general casethere may be more than one sender (i.e. equivalent to A) for a givenrequest.

The DRM Controller performs a set of arbitrary tests against thetransfer request (e.g. does B have sufficient funds, does A officiallyand legally have possession of X, is it within a window of time in whichA is allowed to distribute content etc. etc.) and, assuming these testsare successful, it sends an encryption key E to A. This encryption key Eis taken from a table of encryption key/hash pairs which have beenprovided to the DRM Controller by an external authority such as thecopyright owner of digital content X or the party that controls digitaldistribution of digital content X.

User A encrypts the content using the key provided by the DRM controllerand then calculates a hash over the encrypted form of the content E(X)returning this value to the DRM Controller. Because the encryption key,E, is not known ahead of time, user A cannot know the value of the hasha priori and can only calculate it by performing the Encryption/HashCalculation steps. On checking the returned hash against the hash fromthe table, the DRM controller knows that User A does indeed have thecontent element X and it is in good condition (i.e, it has not beenaltered from the form used to create the key/has pair). The DRMController then instructs both A and B that the transfer may proceed.

The encrypted form of the content E(X) is transferred from user A touser B by arbitrary means that are well known in the art. Once thecontent transfer has completed, B ensures that the received content hasbeen physically written to non-volatile storage (to account for crashesetc. during the next step). B then calculates a hash over the receivedcontent and returns this value to the DRM Controller. If this valuematches the value previously given then the transfer has been successfuland the DRM Controller updates whatever central records are appropriate,while also returning a decrypt key to B to allow it to decrypt thecontent. A record of the transfer is kept for a period of time such thatif B crashed in the period from obtaining the complete content toreceiving the decrypt key and decrypting the content then B couldrequest said key again without incurring additional charges.

It will be noted that the DRM Controller never needed to ‘see’ thecontent. It only requires a set of encrypt key/hash pairs. If thesepairs are generated by an external responsible authority then theorganization running the DRM Controller need never see or have knowledgeof what the content element is. Note that in an extension to theinvention if the key/hash pairs are consumed this would serve as a formof audit and tracking for the content rights holder and would alsoprevent possible attacks based in the re-use of key/hash pairs

In this manner the DRM Controller can certify transfers without everneeding to have access to the content concerned. The content owner canprovide keys and signatures. Because back end systems decide if atransfer should, or should not progress, neither sender or receiver canindividually circumvent the system

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts the architecture of one embodiment of a digital contentdistribution system in accordance with the present invention;

FIG. 2 depicts the architecture of another embodiment of a digitalcontent distribution system in accordance with the present invention;

FIG. 3 depicts the graphical user interface for use of users of the filesharing process of a digital content distribution system in accordancewith the present invention;

FIG. 4 depicts the process flow of the file sharing process in a digitalcontent distribution system in accordance with the present invention;

FIG. 5 depicts an example of the content shared in a digital contentdistribution system in accordance with the present invention; and,

FIGS. 6A-E depict the graphical user interface screens forming theinterface to the DRM self-service web-site in a digital contentdistribution system in accordance with the present invention.

DETAILED DESCRIPTION OF THE DRAWINGS

In FIG. 1 the architecture of a digital content distribution system inaccordance with the present invention is shown. User A communicates witha DRM Self-Service Web-Site 100 using a device 130 a for the purpose ofinputting various information regarding the distribution of contentowned or controlled by User A. Device 130 a may be any type of generalpurpose personal computer (PC), personal digital assistant (PDA), mobilehandset, cellular telephone or other handheld device capable ofcommunicating in a wired or wireless manner with the Internet so as todisplay one or more user input screen such as those discusses below inrelation to FIG. 6 . Device 130 a would need software such as anInternet browser, Wireless Access Protocol (WAP) browser or othersimilar software in order to send and receive data from the DRMSelf-Service Web-Site 100. This type of software is well-known in theart.

User A communicates using device 130 a with DRM Self-Service Web-Site100 in order to specify various parameters with respect to the transferof content between one or more other users such as User B and User C.FIG. 1 shows the arrangement of components within a typical operationaldigital content distribution system. In this example, transfer ofdigital content owned or controlled by User A is transferred betweenUser B and User C using the associated DRM Controller 120. The othercomponents are important for the construction of a physical system butare not as important to the present invention as DRM Controller 120.

DRM Controller 120 communicated with DRM Self-Service Web-Site 100 inorder to receive information regarding how to handle a transfer ofdigital content from one user to another, such as the transfer ofdigital content from User B to User C. User B and User C communicatewith DRM Controller 120 and with each other by using devices 130 b and130 c which devices are similarly enabled to device 130 a describedabove, although devices 130 b and 130 c should contain an interface foruse by an actual person. A typical transaction would begin with sometype of dialog between User B and User C that leads the two to decidethat one has content that it would like to share with the other.

Accounting and Content Web (ACW) Server 140 comprises softwareimplemented on a general purpose computer that is capable of keepingtrack of transfer of digital content and payment of digital content. ACWServer 140 is in communication with DRM Self-Service Web-Site 100 inorder to receive information about the amount of compensation a usersuch as User A desires to receive for transfers of digital contentbetween other user such as User B and User C. ACW Server 140 is also incommunication with SCP Pre-Pay Web Service Server 160 that is anintelligent service control point capable of decrementing an account ofthe user paying for a transfer of content and incrementing one or moreof the accounts of the user transferring content and/or the owner of thecontent being transferred. In this way, P2P transfers of digital contentcan be accomplished with the knowledge and approval of the owner of thecontent who is properly compensated for the transfer. SCP Pre-Pay WebService Server 160 is in communication with the Digital Rights Server(DRS) which is a repository of records associated with the transfer ofdigital content and payment for such transfers. SCP Pre-Pay Web ServiceSever 160 can be any of several known intelligent service control pointssuch as the Telcordia Converged Application Server and/or Real-TimeCharging System.

FIG. 2 depicts a more detailed embodiment of a digital contentdistribution system, in accordance with the present invention. AgainUser A communicates using a device (not shown) through the Internet 220with one or more DRM Self Service servers/servlets 230 in order to inputvarious information about the distribution of digital content owned orcontrolled by User A. ACW Server 140 is broken into two components:Content Registry Web Server 140 a and Content Account Web Server(Digital Rights Management Platform) (“DRMP”) 140 b. Content RegistryWeb Server 140 a manages the information that plays a role in allowingcontent to be forwarded between users. That is, it contains user orcontent-owner “preferences” pertaining to allowing content exchange suchas exchange rights spelled out in traditional DRM systems. ContentAccounting Web Service 140 b keeps track of the amount a user desiresfor transfer of specific digital content and communicated through theInternet 220 using a Simple Object Access Protocol (SOAP) 260 with ISCPpre-pay web-services 160 to enable the account of the users and ownersof content to properly decremented and incremented in accordance withthe payment scheme. Content Accounting Web-Service 140 b can alsocommunicate using Java Data Base Connectivity (JDBC) with DRS 180 inorder to directly access records of users of the digital contentdistribution system.

As with FIG. 1 , User B and User C get permission for a transfer ofdigital content by communicating with DRM Controller 120. DRM Controller120 communicated with Content Accounting Web Service 140 b and ContentRegistry Web Server 140 a. In the case of the former, DRM Controller 120sends information about the transfer so as to enable proper incrementingand decrementing of user accounts. For example, a transfer of digitalcontent from User B to User C could result in a decrementing of theaccount of User C as well as an incrementing of the accounts of User Aand User B. User A, as the owner of the digital content, is likely toreceive the majority of the payment made by User C but User B might alsoreceive a small payment as a reward for being the one distributingcontent on behalf of User/Owner A.

FIG. 3 depicts a few of the graphical user interface (GUI) screens shownby the DRM Controller 120 to users of the system. Interface Screen 310is the P2P transfer control screen. Interface screen 320 is theinterface seen by the receiving peer or user such as User C in theexample transaction in FIGS. 1 and 2 . Interface Screen 330 is theinterface seen by the sending peer/user such as User B.

The flow of content transfer process between User B and User C is shownin FIG. 4 . User B and User C have previously registered with DRMcontroller 120 and have by some arbitrary method decided that they wishto exchange a piece of digital content, X at step 400 of FIG. 4 . User Crequests a copy of digital content X from User B at step 405/410. User Bis willing to accept the request and so sends an acknowledgement back toUser C at step 415. Both User B and User C register their interest inthe digital content X with the DRM Controller 120 at steps 420 and 425respectively. Note that in the general case there may be more than onesender (i.e. equivalent to A) for a given reception. Digital content Xmay be any type of digital information including but not limited todigital music, movies, books, magazines, computer software, audiobooks,etc.

At step 430 the DRM Controller 120 performs a set of arbitrary testsagainst the transfer request. For example the DRM Controller 120 may bedesigned to query whether User C has sufficient funds. Alternatively,DRM Controller may query whether User B legitimately has a copy ofdigital content X, or whether it is a time period in which User A isallowed to distribute content. Any number of arbitrary tests can begenerated. Assuming these tests are successful, DRM Controller 120 sendsan acknowledge (ACK) message back to User C at step 435 and/or anacknowledge (ACK) message with an encryption key E to User B at step440. This encryption key E is taken from a table of encryption key/hashpairs which have been provided to the DRM Controller by an externalauthority. For example, the encryption key/hash pairs may be provided byUser A, the owner or licensed distributor of digital content X.

User B encrypts the content using they key provided by the DRMController 120. User B also performs a hash function (preferably MD5)over the encrypted digital content and returns this hash to the DRMController 120 at an optional step not shown in FIG. 4 . If the hashmatches that in the database of the DRM Controller then the DRMController instructs User A and User B that the transfer may proceed atan additional optional step not depicted in FIG. 4 . User B thentransfers the encrypted content to User C by arbitrary means that arewell known in the art at step 445.

Once the content transfer has completed User C ensures that the receivedcontent has been physically written to non-volatile storage (to accountfor crashes) in a step not shown in FIG. 4 . User C then calculates ahash over the encrypted form of the content E(X) and returns this hashvalue to the DRM Controller 120 at step 450. Because the encryption keyE is not known ahead of time, User C cannot know the value of the hash apriori and can only calculate it by performing the Encryption/HashCalculation steps. On checking the returned hash value against the hashfrom the table the DRM Controller 120 knows that User C does indeed havethe digital content X and that the digital content is in good condition.If this value matches the value provided by the content owner User A andstored by the DRM Controller then a transfer of valid content has beensuccessful and the DRM Controller updates whatever central records areappropriate at step 455, while also returning an acknowledge (ACK)message with a decrypt key to User C to allow User C to decrypt thedigital content X. A record of the transfer is kept for a period of timesuch that if User C crashed in the period from obtaining the completecontent to receiving the decrypt key and decrypting the content thenthey could request said key again without incurring additional charges.

It will be noted that the DRM Controller 120 never needed to ‘see’ orpossess an actual copy of the digital content. DRM Controller 120 onlyrequires a set of encrypt key/hash pairs. If these pairs are generatedby an external responsible authority then the organization running theDRM Controller need never see or have knowledge of what the digitalcontent X is.

In an extension to the invention if the key/hash pairs are consumed thiswould serve as a form of audit and tracking for the content rightsholder and would also prevent possible attacks based in the re-use ofkey/hash pairs. By “consumed” it is meant that the DRM server would usea key/hash pair for one and only one transaction and would never re-usethe transactions for subsequent transactions. Furthermore, the externalrepository could supply the key//has pairs to the DRM server on demand,when users have committed to a content transfer.

FIG. 5 depicts an example of digital content that is being transferredfrom one user to another. Field 510 contains the filenames of thedigital content to be transferred. In this example the digital contentis MP3 encoded music files. Field 520 contains the encrypt and/ordecrypt keys and field 530 contains the related MD5 checksum hash. Oneline from the file set forth in FIG. 5 is all that is needed for the DRMController 120 to be able to validate a specific transfer.

FIGS. 6A-E depict a set of graphical user interface (GUI) screens usedby the DRM Self-Service Web Server 100 in order to gather informationfrom the owner of digital content. Screen 610 of FIG. 6A is a user loginscreen for such a server. Screen 620 of FIG. 6B provides the owner/userwith the ability to select the viewing of account balances, billingactivity, media, and to “top-up” a pre-pay account balance. Screen 630of FIG. 6C provides information on the account balance. Screen 640 ofFIG. 6D enables the user to view the digital content that he or she hastransferred from another source. Screen 650 of FIG. 6E provides aninterface for adding money to a pre-pay wallet for the future purchaseof digital content.

The above description has been presented only to illustrate and describethe invention. It is not intended to be exhaustive or to limit theinvention to any precise form disclosed. Many modifications andvariations are possible in light of the above teaching. The applicationsdescribed were chosen and described in order to best explain theprinciples of the invention and its practical application to enableothers skilled in the art to best utilize the invention on variousapplications and with various modifications as are suited to theparticular use contemplated.

1-25. (canceled)
 26. An apparatus comprising: a user computing deviceconfigured to be in communication with a second computing device and acontroller computing device to receive digital content from the secondcomputing device; the user computing device configured to: send arequest to receive the digital content from the second computing device;notify the controller computing device of the request to receive thedigital content from the second computing device, the controllercomputing device in communication with the second computing device andconfigured to receive authorization from the second computing device tosend the digital content to the user computing device; receive thedigital content from the second computing device in an encrypted form;receive a decryption key from the controller computing device; decryptthe encrypted form of the digital content using the decryption key toreturn the digital content to an original form.
 27. The apparatus ofclaim 26 wherein the user computing device is further configured to:calculate a hash based at least in part on the encrypted form of thedigital content; and send the hash to the controller computing device todetermine whether the received digital content is valid.
 28. Theapparatus of claim 26 wherein to notify the controller computing deviceincludes requesting the controller computing device facilitate transferof the digital content from the second computing device to the usercomputing device.
 29. The apparatus of claim 26 wherein the usercomputing device is further configured to receive an acknowledgementmessage from the controller computing device indicating the controllercomputing device will facilitate transfer of the digital content fromthe second computing device to the user computing device.
 30. Theapparatus of claim 26 wherein the user computing device is furtherconfigured to determine that the received digital content has beenphysically written to non-volatile storage of the user computing device.31. The apparatus of claim 26 wherein the digital content is one or moreof a digital song, movie, book, magazine, computer software, andaudiobook.
 32. The apparatus of claim 26 wherein the user computingdevice communicates with at least one of the second computing device andthe controller computing device via the internet.
 33. A non-transitorycomputer readable medium having instructions stored thereon forreceiving digital content at a user computing device from a secondcomputing device, the instructions configured to cause one or morecomputing devices to perform operations comprising: sending a request toreceive digital content from the second computing device; notifying acontroller computing device of the request to receive the digitalcontent from the second computing device, the controller computingdevice in communication with the second computing device and configuredto receive authorization from the second computing device to send thedigital content to the user computing device; receiving the digitalcontent from the second computing device in an encrypted form; receivinga decryption key from the controller computing device; decrypting theencrypted form of the digital content using the decryption key to returnthe digital content to an original form.
 34. The non-transitory computerreadable medium according to claim 33 further comprising: calculating ahash based at least in part on the encrypted form of the digitalcontent; and sending the hash to the controller computing device todetermine whether the received digital content is valid.
 35. Thenon-transitory computer readable medium according to claim 33 whereinnotifying the controller computing device includes requesting thecontroller computing device facilitate transfer of the digital contentfrom the second computing device to the user computing device.
 36. Thenon-transitory computer readable medium according to claim 33 furthercomprising receiving an acknowledgement message from the controllercomputing device indicating the controller computing device willfacilitate transfer of the digital content from the second computingdevice to the user computing device.
 37. The non-transitory computerreadable medium according to claim 33 further comprising determiningthat the received digital content has been physically written tonon-volatile storage of the user computing device.
 38. Thenon-transitory computer readable medium according to claim 33 whereinthe digital content is one or more of a digital song, movie, book,magazine, computer software, and audiobook.
 39. The non-transitorycomputer readable medium according to claim 33 wherein notifying thecontroller includes communicating with the controller computing devicevia the internet.